<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>Memory-only or Flash configurations</title>
    <link rel="stylesheet" href="gettingStarted.css" type="text/css" />
    <meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
    <link rel="start" href="index.html" title="Berkeley DB Programmer's Reference Guide" />
    <link rel="up" href="program.html" title="Chapter 17.  Programmer Notes" />
    <link rel="prev" href="program_namespace.html" title="Name spaces" />
    <link rel="next" href="program_cache.html" title="Disk drive caches" />
  </head>
  <body>
    <div xmlns="" class="navheader">
      <div class="libver">
        <p>Library Version 12.1.6.2</p>
      </div>
      <table width="100%" summary="Navigation header">
        <tr>
          <th colspan="3" align="center">Memory-only or Flash
        configurations</th>
        </tr>
        <tr>
          <td width="20%" align="left"><a accesskey="p" href="program_namespace.html">Prev</a> </td>
          <th width="60%" align="center">Chapter 17.  Programmer Notes </th>
          <td width="20%" align="right"> <a accesskey="n" href="program_cache.html">Next</a></td>
        </tr>
      </table>
      <hr />
    </div>
    <div class="sect1" lang="en" xml:lang="en">
      <div class="titlepage">
        <div>
          <div>
            <h2 class="title" style="clear: both"><a id="program_ram"></a>Memory-only or Flash
        configurations</h2>
          </div>
        </div>
      </div>
      <p>
        Berkeley DB supports a variety of memory-based
        configurations for systems where filesystem space is either
        limited in availability or entirely replaced by some
        combination of memory and Flash. In addition, Berkeley DB can
        be configured to minimize writes to the filesystem when the
        filesystem is backed by Flash memory.
    </p>
      <p>
        There are four parts of the Berkeley DB database environment
        normally written to the filesystem: the database environment
        region files, the database files, the database environment log
        files and the replication internal files. Each of these items
        can be configured to live in memory rather than in the
        filesystem:
    </p>
      <div class="variablelist">
        <dl>
          <dt>
            <span class="term">The database environment region files:</span>
          </dt>
          <dd>
            <p> 
                    Each of the Berkeley DB subsystems in a
                    database environment is described by one or more
                    regions, or chunks of memory. The regions contain
                    all of the per-process and per-thread shared
                    information (including mutexes), that comprise a
                    Berkeley DB environment. By default, these regions
                    are backed by the filesystem. In situations where
                    filesystem backed regions aren't optimal,
                    applications can create memory-only database
                    environments in two different types of memory:
                    either in the application's heap memory or in
                    system shared memory. 
                </p>
            <p>
                    To create the database environment in heap
                    memory, specify the <a href="../api_reference/C/envopen.html#envopen_DB_PRIVATE" class="olink">DB_PRIVATE</a> flag to the
                    <a href="../api_reference/C/envopen.html" class="olink">DB_ENV-&gt;open()</a> method. Note that database environments
                    created in heap memory are only accessible to the
                    threads of a single process, however.
                </p>
            <p> 
                    To create the database environment in system
                    shared memory, specify the <a href="../api_reference/C/envopen.html#envopen_DB_SYSTEM_MEM" class="olink">DB_SYSTEM_MEM</a> flag to
                    the <a href="../api_reference/C/envopen.html" class="olink">DB_ENV-&gt;open()</a> method. Database environments
                    created in system memory are accessible to
                    multiple processes, but note that database
                    environments created in system shared memory do
                    create a small (roughly 8 byte) file in the
                    filesystem, read by the processes to identify
                    which system shared memory segments to use.
                </p>
            <p>
                    For more information, see <a class="xref" href="env_region.html" title="Shared memory regions">Shared memory regions</a>.
                </p>
          </dd>
          <dt>
            <span class="term">The database files:</span>
          </dt>
          <dd>
            <p> 
                    By default, databases are periodically flushed
                    from the Berkeley DB memory cache to backing
                    physical files in the filesystem. To keep
                    databases from being written to backing physical
                    files, pass the <a href="../api_reference/C/mempset_flags.html#mpool_set_flags_DB_MPOOL_NOFILE" class="olink">DB_MPOOL_NOFILE</a> flag to the
                    <a href="../api_reference/C/mempset_flags.html" class="olink">DB_MPOOLFILE-&gt;set_flags()</a> method. This flag implies the
                    application's databases must fit entirely in the
                    Berkeley DB cache, of course. To avoid a database
                    file growing to consume the entire cache,
                    applications can limit the size of individual
                    databases in the cache by calling the
                    <a href="../api_reference/C/mempset_maxsize.html" class="olink">DB_MPOOLFILE-&gt;set_maxsize()</a> method. 
                </p>
          </dd>
          <dt>
            <span class="term">The database environment log files:</span>
          </dt>
          <dd>
            <p> 
                    If a database environment is not intended to be
                    transactionally recoverable after application or
                    system failure (that is, if it will not exhibit
                    the transactional attribute of "durability"),
                    applications should not configure the database
                    environment for logging or transactions, in which
                    case no log files will be created. If the database
                    environment is intended to be durable, log files
                    must either be written to stable storage and
                    recovered after application or system failure, or
                    they must be replicated to other systems.
                </p>
            <p>
                    In applications running on systems without any
                    form of stable storage, durability must be
                    accomplished through replication. In this case,
                    database environments should be configured to
                    maintain database logs in memory, rather than in
                    the filesystem, by specifying the
                    <a href="../api_reference/C/envlog_set_config.html#log_set_config_DB_LOG_IN_MEMORY" class="olink">DB_LOG_IN_MEMORY</a> flag to the <a href="../api_reference/C/envlog_set_config.html" class="olink">DB_ENV-&gt;log_set_config()</a>
                    method. 
                </p>
          </dd>
          <dt>
            <span class="term">The replication internal files:</span>
          </dt>
          <dd>
            <p>
                    By default, Berkeley DB replication stores a
                    small amount of internal data in the filesystem.
                    To store this replication internal data in memory
                    only and not in the filesystem, specify the
                    <a href="../api_reference/C/repconfig.html#config_DB_REP_CONF_INMEM" class="olink">DB_REP_CONF_INMEM</a> flag to the <a href="../api_reference/C/repconfig.html" class="olink">DB_ENV-&gt;rep_set_config()</a> method
                    before opening the database environment. 
                </p>
          </dd>
        </dl>
      </div>
      <p>
        In systems where the filesystem is backed by Flash memory,
        the number of times the Flash memory is written may be a
        concern. Each of the four parts of the Berkeley DB database
        environment normally written to the filesystem can be
        configured to minimize the number of times the filesystem is
        written:
    </p>
      <div class="variablelist">
        <dl>
          <dt>
            <span class="term">The database environment region files:</span>
          </dt>
          <dd>
            <p> 
                    On a Flash-based filesystem, the database
                    environment should be placed in heap or system
                    memory, as described previously. 
                </p>
          </dd>
          <dt>
            <span class="term">The database files:</span>
          </dt>
          <dd>
            <p> 
                    The Berkeley DB library maintains a cache of
                    database pages. The database pages are only
                    written to backing physical files when the
                    application checkpoints the database environment
                    with the <a href="../api_reference/C/txncheckpoint.html" class="olink">DB_ENV-&gt;txn_checkpoint()</a> method, when database
                    handles are closed with the <a href="../api_reference/C/dbclose.html" class="olink">DB-&gt;close()</a> method, or
                    when the application explicitly flushes the cache
                    with the <a href="../api_reference/C/dbsync.html" class="olink">DB-&gt;sync()</a> or <a href="../api_reference/C/mempsync.html" class="olink">DB_ENV-&gt;memp_sync()</a> methods.
                </p>
            <p>
                    To avoid unnecessary writes of Flash memory due
                    to checkpoints, applications should decrease the
                    frequency of their checkpoints. This is especially
                    important in applications which repeatedly modify
                    a specific database page, as repeatedly writing a
                    database page to the backing physical file will
                    repeatedly update the same blocks of the
                    filesystem. 
                </p>
            <p>
                    To avoid unnecessary writes of the filesystem
                    due to closing a database handle, applications
                    should specify the <a href="../api_reference/C/dbclose.html#dbclose_DB_NOSYNC" class="olink">DB_NOSYNC</a> flag to the
                    <a href="../api_reference/C/dbclose.html" class="olink">DB-&gt;close()</a> method. 
                </p>
            <p> 
                    To avoid unnecessary writes of the filesystem
                    due to flushing the cache, applications should not
                    explicitly flush the cache under normal conditions
                    – flushing the cache is rarely if ever
                    needed in a normally-running application.
                </p>
          </dd>
          <dt>
            <span class="term">The database environment log files:</span>
          </dt>
          <dd>
            <p>
                    The Berkeley DB log files do not repeatedly
                    overwrite the same blocks of the filesystem as the
                    Berkeley DB log files are not implemented as a
                    circular buffer and log files are not re-used. For
                    this reason, the Berkeley DB log files should not
                    cause any difficulties for Flash memory
                    configurations.
                </p>
            <p>
                    However, as Berkeley DB does not write log
                    records in filesystem block sized pieces, it is
                    probable that sequential transaction commits (each
                    of which flush the log file to the backing
                    filesystem), will write a block of Flash memory
                    twice, as the last log record from the first
                    commit will write the same block of Flash memory
                    as the first log record from the second commit.
                    Applications not requiring absolute durability
                    should specify the <a href="../api_reference/C/envset_flags.html#set_flags_DB_TXN_WRITE_NOSYNC" class="olink">DB_TXN_WRITE_NOSYNC</a> or
                    <a href="../api_reference/C/envset_flags.html#envset_flags_DB_TXN_NOSYNC" class="olink">DB_TXN_NOSYNC</a> flags to the <a href="../api_reference/C/envset_flags.html" class="olink">DB_ENV-&gt;set_flags()</a> method
                    to avoid this overwrite of a block of Flash
                    memory.
                </p>
          </dd>
          <dt>
            <span class="term">The replication internal files:</span>
          </dt>
          <dd>
            <p> 
                    On a Flash-based filesystem, the replication
                    internal data should be stored in memory only, as
                    described previously.
                </p>
          </dd>
        </dl>
      </div>
    </div>
    <div class="navfooter">
      <hr />
      <table width="100%" summary="Navigation footer">
        <tr>
          <td width="40%" align="left"><a accesskey="p" href="program_namespace.html">Prev</a> </td>
          <td width="20%" align="center">
            <a accesskey="u" href="program.html">Up</a>
          </td>
          <td width="40%" align="right"> <a accesskey="n" href="program_cache.html">Next</a></td>
        </tr>
        <tr>
          <td width="40%" align="left" valign="top">Name spaces </td>
          <td width="20%" align="center">
            <a accesskey="h" href="index.html">Home</a>
          </td>
          <td width="40%" align="right" valign="top"> Disk drive caches</td>
        </tr>
      </table>
    </div>
  </body>
</html>
